UBRARY 

TECHNICAL  REPORT 
NAVAL  POSIC  AOUA 
MONTEREY,    CALIFORI 


NPS52-80-001 


NAVAL  POSTGRADUATE  SCHOOL 

Monterey,  California 


THE 

TEXT 

EDITOR  AS  A 

UNIFORM 

MAN/MACHINE 

INTERFACE. 

A  PROPOSAL  FOR  A  STANDARD 

EDITOR 

Lyle  Ashton 

Cox,  Jr 

February 

1980 

Approved  for  public  release;  distribution  unlimited 


FEDDOCS 

D  208.14/2:NPS-52-80-001 


26  Feb  1980 


NAVAL  POSTGRADUATE  SCHOOL 
Monterey,  California 


Rear  Admiral  J.  J.  Ekelund 
Superintendent 


Jack  R.  Borsting 
Provost 


The  work  reported  herein  was  supported  in  part  by  the  Foundation 
Research  Program  of  the  Naval  Postgraduate  School  with  funds  provided 
by  the  Chief  of  Naval  Research. 

Reproduction  of  all  or  part  of  this  report  is  authorized. 

This  report  was  prepared  by: 


Unclassified 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Data  Entered) 


REPORT  DOCUMENTATION  PAGE 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


1.     REPORT  NUMBER 

NPS52-80-001 


2.  GOVT   ACCESSION  NO 


3.     RECIPIENT'S  CATALOG   NUMBER 


4.     TITLE  (and  Subtitle) 

The  Text  Editor  as  A  Uniform  Man/Machine 
Interface.  A  Proposal  for  a  Standard  Editor 


5.     TYPE  OF  REPORT  &  PERIOD  COVERED 


Technical   Report 


6.  PERFORMING  ORG.  REPORT  NUMBER 


7.     AUTHORfsj 

Lyle   Ashton   Cox,    Jr, 


8.     CONTRACT  OR  GRANT  NUMBERfs) 


9.     PERFORMING  ORGANIZATION   NAME  AND  ADDRESS 

Naval  Postgraduate  School 
Monterey,  CA  93940 


tO.  PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  4  WORK  UNIT  NUMBERS 

61152N;  RR000-01-10 
N0001480WR00054 


11.     CONTROLLING  OFFICE  NAME   AND   ADDRESS 

Naval  Postgraduate  School 
Monterey,  CA  93940 


12.     REPORT  DATE 

February    1980 


13.     NUMBER  OF   PAGES 


14.     MONITORING  AGENCY  NAME  ft    ADDRESSf//  different  from  Controlling  Office) 


15.     SECURITY  CLASS,  (of  thle  report) 

Unclassified 


15«.     DECLASSIFI  CATION/  DOWN  GRADING 
SCHEDULE 


16.     DISTRIBUTION   ST  ATEMEN  T  (of  this  Report) 

Approved  for  public  release;  distribution  unlimited. 


17.     DISTRIBUTION  STATEMENT  (of  the  abatract  entered  In  Block  20,  If  different  from  Report) 


IB.     SUPPLEMENTARY   NOTES 


19.     KEY  WORDS  (Continue  on  reverse  aide  If  neceaaary  and  Identity  by  block  number) 

Text  Editor 
Software  Engineering 
Computer  Networks 


20.     ABSTRACT  (Continue  on  raveraa  aide  It  neceaaary  and  Identity  by  block  number) 

There  is  a  substantial  group  of  professionals,  scientists,  engineers,  and 
managers  who  are  justifiably  reluctant  to  use  computer  networks  such  as  the 
ARPANET.   This  phenomenon  continues  despite  the  fact  that  they  recognize  some 
of  the  benefits  of  computational  assistance,  that  they  have  had  experience 
using  computer  systems,  and  that  they  have  access  to  such  a  network.   Their 
reluctance  usually  stems  from  the  feeling  that  the  very  machines  and  systems 
is  not  justified  by  the  occasional  or  intermittent  nature  of  their  computational 


DD 


FORM 
1  JAN  73 


1473 


EDITION  OF    1  NOV  65  IS  OBSOLETE 
S/N    0102-014- 6601   |  1 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (When  Data  Bntarad) 


Unclassified 


-ttumTY   CLASSIFICATION   OF   THIS  PAGE("H7>en  Dmta  Entered) 


problems.   In  learning  to  use  a  new  system,  a  large  part  of  the  familiariza- 
tion effort  is  spent  in  trying  to  learn  to  use  a  new  text  editing  program. 
If  such  a  utilit  y  program  were  standardized  and  made  available  on  all  of 
the  machines  on  the  network,  a  large  obstacle  to  the  efficient  use  of  such 
systems  might  be  removed.   The  design  of  such  a  system,  a  Standard  Line 
EDitor  called  "SLED"  is  proposed  here. 


SECURITY  CLASSIFICATION  OF  THIS  PAGEfWhan  Date  Entered) 


ABSTRACT 

There  is  a  substantial  group  of  professionals,  Scientists, 
engineers,  and  managers  who  are  justifiably  reluctant  to  use  computer 
networks   such  as  the  ARPANET.   This  phenomenon  continues  despite  the  fact 
that  they  have  had  experience  using  computer  systems,  and  that  they  have 
access  to   such  a  network.   Their  reluctance  usually  stems  from  the  feeling 
that  the  very  great  effort  required  to  familiarize  themselves  with  new 
machines  and  systems  is  not  justified  by  the  occasional  or  intermittent 
nature  of  their  computational  problems.   In  learning  to  use  a  new  system, 
a  large  part  of  the  familiarization  effort  is  spent  in  trying  to  learn  to 
use  a  new  text  editing  program.   If  such  a  utility  program  were  standar- 
dized and  made  available  on  all  of  the  machines  on  the  network,  a  large 
obstacle  to  the   efficient  use  of  such  systems  might  be  removed.   The  de- 
sign of  such  a   system,  a  Standard  Line  EDitor  called  "SLED"  is  proposed 
here. 


The  Text  Editor  as  A  Uniform  Kan/Yachine  Interface 
A  Proposal  for  a  Standard  Editor 

by 
Lyle  Ashton  Cox  Jr. 

Department  of  Computer  Science 
Naval  Postgraduate  S^ho^i 
Monterey,  California 

ABSTRACT 

There  is  a  substantial  group  of  professionals,  scientists, 
engineers,  ard  managers  who  are  justifiably  reluctant  to  use 
computer  networks  such  as  the  ARPANET.  This  phenomenon  continues 
despite  the  fact  that  they  recognize  some  of  the  benefits  of 
computational  assistance,  that  they  have  had  °xpenicnce  using 
computer  systems,  and  that  they  have  access  to  such  a  network. 
Their  reluctance  usually  stems  from  the  feeling  that  the  very 
great  effort  required  to  familiarize  themselves  with  new 
machines  and  systems  is  not  justified  by  tve  occasional  on 
intermittent  nature  of  their  computational  problems.  In  learning 
to  use  a  new  system,  a  large  part  of  the  familiarization  effort, 
i s  spent  in  trying  to  learn  to  use  a  new  text  editing  pnogram. 
If  such  a  utility  program  were  standardized  and  rede  available 
on  all  of  the  machines  on  the  network,  a  largp  obstacle  to  the 
efficient  use  of  such  systems  migvt  be  removed.  The  design  of 
such  a  systerr,  a  Standard  Line  EPitor  called  "SLED"  is  proposed 
h°re . 


BACKGROUND 


The  United  States  Navy  is  currently  conducting  en 
experiment  to  determine  the  effectiveness  of  computer  networking 
in  providing  the  computing  support  required  by  thf=  Kavy 
laboratories.  In  the  course  of  this  experiment,  significant 
resources  of  the  laboratories  are  bein±>  organized  into  a  "i\Avy 
Laboratory  Computer  Network"  or  "NALCON"  (1)  (?)  to  promote  the 
efficient  use  of  the  physical  and  logical  resources  of  the  Navy 
laboratories . 

While  the  NALCCN  system  was  being  implemented,  it  was 
recognized  that  software  technology  often  poses  greater  problems 
than  does  the  hardware  design  and  construction.  In  response  to 
this,  the  Navy  Laboratory  Computer  Corrrittee  (NLCC)  forrei  a 
Software  Technology  V'crking  Group.  It  is  the  goal  of  this  group 
to  address  the  specific  software  problems  of  N/LCON,  and  to 
consider  the  larger  problems  of  software  technology  in  the  Navy 
computing  community. 

After  a  series  of  meetings,  the  Software  Technology  Working 
Croup  reported  (o)  that  the  number  and  diverse  nature  of  text 
editor  programs  constituted  a  significant  obstacle  (both  real 
and  psychological)  to  the  efficient  use  of  network  nesources.  It 
was  suggested  that  either  a  standard  editor  be  developed,  or 
that  all  network  computers  contain  editors  with  a  standard 
subset  of  commands. 


Subsequently,  work  was  undertaken  at  the  Naval  Postgraduate 
School  to  determine  the  desirable  characteristics  which  such  en 
editor  should  display,  and  to  define  or  specify  the  user 
interface  for  this  proposed  standard  editor.  The  results  of  this 
effort  are  described  below. 

PHILOSOPHY 


Before  we  describe  the  proposed  standard  editor,  it  is 
appropriate  that  several  non-technical,  philosophical,  aspects 
of  the  editor  design  be  discussed. 

It  should  be  recognized  that  any  editor  will  certain  some 
characteristics  which  significant  portions  of  the  computer  user 
community  will  find  objectionable.  The  implementation  of  text 
editor  features  is  often  a  matter  of  personal  tacte.  ^ou  can  not 
please  all  of  the  people  all  of  the  tire.  I»e  believe  that  the 
proposed  editor  is  well  thought  out,  and  is  based  upon  the 
experience  of  thousands  of  computer  users  spannir£  well  oven  ? 
decade  of  network  and  timesharing  experience.  Our  solution  is 
certainly  not  unique.  There  are  other  solutions.  Ive  have 
ccnfid°nce  that  ours  is  or°  of  the  better  possibilities,  and 
should  seriously  be  considered  as  a  standard. 

With  regards  to  the  specification  itself,  in  th<=  following 
sections  we  will  attempt  to  describe  the  editor  i '"forma  11;-, 
using  a  mixture  of  two  technioues.  The  description  will  not  be  a 
rigorous  specification  in  the  software  engineering  sense?  nor 
will  it  be  a  "users  view"  of  the  editor.  3y  combining  aspects  of 
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these  two  techniques  -  specifications  and  a  "users  introduction" 
type  description  of  the  editor  -  we  hope  to  both  describe  the 
editor  in  sufficient  detail  that  it  can  be  implemented,  and  £iv° 
the  readers  a  "feel"  for  using  the  editor.  V.e  ask  that  the 
reader  keep  in  mind  the  goal  of  the  standard  editor  project,  and 
this  philosophy  while  reading  the  remainder  of  this  paper. 

TEE  GOALS  OF  A  "STANDARD  EDITO?" 


The  goal  of  thp  Standard  Editor  project  is  to  definp  and 
develop  a  simple  and  easy  to  use  text  editor  program  whi^h  can 
he  readily  implemented  or  a  wide  variety  of  host  machines  and 
operating  systems.  This  objective  and  the  computer  network 
context  of  its  development  allow  further  definition  of  SIED 
requirements . 

The  usage  envisioned  for  SLED  is  twofold*  casual  use  by 
persons  local  to  the  host?  eni  use  by  occasional  network  quests 
of  the  host.  Such  a  simple,  basic  editor  can  not  and  should  not 
attempt  to  replace  the  principal  system  editor  programs 
available  on  the  host  machines.  Since  the  scope  of  usage  5s  thus 
reduced,  no  attempt  need  be  made  to  design  SLED  to  be  all 
powerful  (and  hence  complex).  SLED  only  needs  to  support  the 
basic  text  editing  functions,  and  if  these  functions  are 
supported  in  a  well  designed,  wpII  documented,  easy  to  use 
implementation,  the  basic  goals  of  the  project  can  be  fulfilled. 

The    limited   scope   also   allows   implementations   to   be 


accomplished  without  undue  attention  to  questions  of  ex°cuticn 
efficiency  which  are  vital  in  the  design  of  a  principal  system 
editor.  Thus  implementations  can  be  nealized  using  higher  level 
computer  programming  languages,  with  emphasis  on  portability  and 
system  independ°nce. 

The  wide  variety  of  users  anticipated,  and  the  large  number 
of  Implementations,  requires  several  characteristics  of  the 
editor  to  be  present  in  all  its  implementations.  Certainly  all 
the  implementations  must  be  as  nearly  uniform  (in  terns  of  the 
user  interface)  as  current  software  technology  permits.  In 
designing  the  editor,  the  usage  and  commands  must  be  kept 
simple.  The  commands  must  function  "intuitively"  and  be  easy  to 
learn  and  remember.  Further,  no  special  terminal  character  set 
or  line  speed  assumptions  can  be  made. 

SPECIFYING  THE  EDITOR 


From  these  general  requirements,  a  rore  detailed 
specification  was  developed.  Great  effort  was  made  to  keep  the 
editor  simple  (from  the  user's  point  of  view).  Of  secondary 
importance  was  machine  and  system  independence,  and  portability 
of  the  implementations.  The  resultant  specifications  are 
described  informally  (fror  the  point  of  vi°w  of  the  usen)  below. 

The  constraints  upon  terminals  and  line  speed*,  coupled 
with  the  restricted  nature  of  the  editor  led  us  to  sp]ect  a 
"line  oriented  editor"  approach.  Vith  the  addition  of  a  logical 
line   terminator   character   and  a  simple  display  function,  line 
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oriented  editors  have  been  shown  to  function  efficiently  with  a 
variety  of  terminals  using  a  wide  rangp  of  line  speeds  in  a  time 
sharing  environment  (4), (5). 

A  minimum  set  of  commands  consistent  with  easy  use  has  been 
selected  (5), (6).  These  commands  draw  their  mnemonic  symbols 
from  the  first  letters  of  their  key  words  taken  in  normal 
English  language  order.  "For  example,  the  command  to  "insert  text 
<A>fter  <L>ine  5"  is  "A15".  There  was  some  desire  to  limit  the 
mnemonics  to  single  characters.  While  this  would  decrease  the 
total  number  of  key  strokes  required  in  an  edit  session,  the 
decrease  is  a  small  percentage  of  the  total  number  of  characters 
typed.  The  advantages  of  natural  English  language  command 
ordering  combined  with  the  relative  independence  from  rany  other 
editors  which  use  single  character  commands  (hence  decreasing 
the  chances  of  confusion  and  error  for  persons  inadvertently 
reverting  to  other  editor  commands)  was  considered  to  outweigh 
the  advantages  of  exclusive  use  of  single  character  mnemonics. 

There  are  a  total  of  eleven  commands,  only  seven  of  which 
need  be  used  to  obtain  full  text  editing  capability.  These 
eleven  commands  can  be  rougnly  subdivided  into  five  basic 
groups : 

1.  Line  Insertion  and  replacement  commands   (two  commands) 

2.  String  Replacement  commands  (one  basic  command) 

3.  String  Search  commands  (one  basic  command; 

4.  Terminal  Output  commands  (four  cormands) 

5.  Control  commands  (three  commands) 

These  commends  are  more  fully  described  in  Table  1. 
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Since  many  of  the  prospective  SLED  users  are  only 
occasional  users  of  computer  systems,  initiation  cf  all 
implementations  should  he  uniformly  commenced  by  typing  only 
"SLED<Carrage-return">"  after  linking  and  lodging  i^to  the 
network-  host  machine.  At  this  point,  thp  casual  user  may  ask  for 
a  menu  to  refresh  his  memory  as  to  the  basic  commands  and  their 
format  via  the  "m"  command.  (See  Figure  1  for  an  exanple  of  the 
<m*>enu  output.)  The  possibility  of  SLED  users  equipped  with  low 
speed  terminals  or  low  speed  lines  rpquir°s  that  this  message  be 
kept  brief.  Two  incorrectly  formatted  requests  in  series  will 
automatically  cause  the  execution  of  a  <y>enu  cormard. 

A  more  experienced  user  may  directly  execute  th^  <V>°rsicn 
command  which  will  print  a  brief  version  identification,  the 
name  and  telephone  numbers  of  consultants  who  can  provide  some 
help  if  required,  and  will  explicitly  identify  any  features  of 
the  editor  which  are  required  by  the  local  system.  A  sarple  of 
the  <V>ersion  output  is  shown  in  Figure  2. 

The  editor,  like  many  other  editors,  features  essentially 
two  modes:  "Edit  command"  mode  and  "t^xt  Insert'  mode.  SLEI, 
when  initialized,  starts  in  "Fdit  command"  mode,  and  requests  ar 
edit  command  from  the  user's  console  by  transmitting  to  the  user 
the  prompt  "F>".  This  prompt  will  also  be  transmitted  following 
the  successful  execution  of  any  edit  command  message  line 
(except  one  containing  the  "<TQ>uit"  command)  and  the  editor  will 
await  further  instructions.  Following  this  prorpt  the  user  can 
enter   any   command   shown  in  Table  1.  Commands  and  their  field? 
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can  be  separated  by  any  valid  logical  message  terminator  (see 
Figure  2).  The  character  "Carriage  return"  always  serves  as  a 
message  terminator.  One  other  character  is  provided  for  use  as  a 
message  terminator,  and  this  is  changible  at  the  direction  of 
the  user  via  the  <C>han&e  <TT>erminator  command.  This  feature 
allows  the  "stacking"  of  editor  commands  within  a  single 
physical  line  of  input.  This  feature  is  demonstrated  below,  and 
is  extremely  convenient  in  a  network  operating  environment.  If 
the  command  executed  by  the  user  causes  the  editor  to  enter  the 
"text  Insert"  node,  the  editor  will  prompt  the  user  for  data 
with  the  symbol  "l>".  All  text  entered  after  these  prompts  will 
be  copied  directly  to  the  text  file,  and  will  not  be  interpreted 
as  edit  commands.  The  only  way  to  return  from  the  "text  Insert" 
mode  to  the  "Edit  command"  mode  is  by  entering  a  single  message 
consisting  of  ONLY  a  period  ".". 

V'hile  these  two  prompts  are  somewhat  inconvenient  to  users 
desiring  to  operate  in  a  "non-echo"  mode,  they  are,  in  general, 
necessary  for  two  reasons.  They  are  useful  in  corfirmlrg  to  the 
(inexperienced)  user  which  mode  he  is  currently  in;  and  they  are 
vital  in  systems  which  do  not  save  data  buffers  as  a 
synchronization  mechanism  (for  example  a  PDP-11  using  the  PSX-11 
operating  system  which  does  NOT  allow  "type  ahead"  of  logical 
read  commands). 

These  modes  and  their  functions  can  be  better  understood 
from  the  following  example  of  SLED  usage: 
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EXAMPLE  1:  USING  SLED  TO  CREATE  A  EILE 
(Fror  a  UNIX  Like  implementation) 

^SLED 

E>0 

fllename?>NEW.file 

-creating  file   "NEW.file"- 

E>AL0 

I>  First    text   line 

I>Second    text   line 

I>  Third    text    line 

I>. 

E>L1,3 

1  First  text  line 

2  Second  text  line 

3  Third  text  line 
F>Q 

% 

In   the  above  example,  the  SLET  editor  was  used  to  create  a 

new   text   file,  end  to  enter  three  sirplp  linps  of  text.  Use  of 

the     logical   message   terminator   key   (if   available}   can 

significantly   simplify   the   use  of  the  editor.  This  key  allows 

several   command  lines  (either  edit  commands  or  insert  lines)  tc 

be  entered  on  a  single  physical  line  from  the  terminal.  Example 

2   shows  the  use  of  the  logical  message  terminator  key  («^hown  as 

"$")   to   "stack"   several  editor  commands  into  a  single  line  of 

input.   The  effect  of  the  commands  shown  in  this  example  are  the 

same  as  those  shown  in  Exarple  1. 

FXAMPLF  2:   THE  LOGICAL  MESSAGE  TFEMINATOF 
(Same  effect  as  Example  lj 

%SLEL 

E>0£NEW.file$ALP 

-creating  file  "NEfc.file"- 

I>  First  text  line$Second  text  line 

I>  Third  text  line$.  $H  t?sC 

1  First  text  line 

2  Second  text  line 

3  Third  text  line 
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Note  that  in  the  fifth  line  of  the  above  example,  a.  line  of 
text  was  inserted,  and  then  the  insert  mode  was  terminated  (by 
sending  a  message  consisting  of  only  a  "."  delimited  by  the 
logical  message  terminator)  and  "Edit  mode"  commands  were  then 
sent.  It  is  this  power  of  transmitting  multiple  messages 
delimited  by  a  reserved  key  which  allows  those  users  with  slow 
terminals  or  those  experiencing  long  data  transmission  delays 
over  the  network  circuits  to  effectively  use  the  editor. 

Many  persons  considering  the  editor  instruction  set  in 
Table  1  ask  how  it  is  possible  to  delete  lines  and  patterns  with 
this  editor.  These  functions  are  acomplished  with  the  use  of  the 
"replace"  functions,  replacing  the  items  to  be  deleted  with 
"nothing".  In  the  context  of  this  editor,  a  "string"  consists  of 
a  sequence  of  characters  which  does  not  contain  any  of  the 
logical  message  terminators.  Thus,  a  string  is  a  portion  of  a 
line  since  all  lines  terminate  with  a  <RETURN>  which  is  a 
terminator.  To  replace  portions  of  lines  one  uses  the  <R>eplace 
<S>tring  command,  while  the  <R>eplace  <L>ine  command  is  used  for 
larger  modifications.  For  example,  consider  the  file  created  in 
Fxample  2:  supppose  we  wanted  to  delete  the  string  "text"  in  the 
first  line,  and  delete  the  entire  third  line.  Using  the  "RS"  and 
"RL"  commands  this  could  be  accomplished  as  shown  in  Fxample  3. 
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EXAMPLE  3:  DELETING  STRINGS  AND  LINES 

%SLED 

E>0$NEW.file 

-  3  lines  in  file  "NEW.file"- 

F>L1 

1   First  text  line 
E>RS$text$$Ll 

1      First      line 
E>RL3$.$S1 

1  First   line 

2  Second  text  line 
E>Q 

% 

In  the  above  example,  the  pattern  to  be  deleted  in  line 
number  one  was  replaced  with  a  string  consisting  of  no 
characters.  The  third  line  was  deleted  by  replacing  it  with  a 
null  line  (ie.  entering  INSERT  mode,  and  exiting  -via  a  message 
consisting  of  only  a  period-  without  entering  any  data).  In  much 
the  same  manner  the  desire  to  insert  text  "Before  Line  n"  can  be 
accomplished  with  commands  to  insert  text  "A^ter  Line  n-l". 

SIED   implementations   must   also  cushion  the  user  from  his 

mistakes   (ie.   provide   "fail   soft"  features).  Ecr  pxample,  an 

attempt   to   open   a   non   existant  file  should  produce  an  error 

message  as  shown  in  Example  4. 

EXAMPLE  4:  Soft  Failure 

%SLFD 

2>L1 

-no  text  file  open- 

ENOsNEW.file 

2    lines  in  file  "MEW. file" 
E>0 
% 

In  addition  to  the  normal  demands  of  defensive  programming, 
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the  nature  of  the  editor  requires  that  careful  attention  "be  paid 

to  error  detection  and  recovery.  The  variety  of  terminal  types 

and  line   speeds   requires  that  the  SLED  messages  be  both  clear 

and  concise.  The  minimum  set  of  SLED  advisory  messages  is  shewn 

in  Table  2,  along  with  the  circumstances  which  will  cause  them 

to  be  generated.   Ml   implementations   must   detect   these 
situations   and   recover  gracefully.  Individual  implementations 

are  encouraged  to  perform  more  sophisticated  consistency  checks 

for  abnormal  user  and  system  conditions. 

CONCLUSIONS 

Significant  increases  in  the  productivity  of  computing 
professionals  can  be  realized  if  we  can  rake  our  existing 
computer  resources  more  "usabl<=".  The  ultimate  goal  -the 
creation  of  an  effective  and  uniform  man/computer  interface-  is 
perhaps  idealistic  and  unachievable.  There  are  however,  a  number 
of  areas  where  we  can  achieve  success,  and  make  more  efficient 
usage  of  our  human  and  machine  resources.  Cne  such  area  is 
uniformity  of  software  development  tools  in  distributed 
computing  systems. 

The  Standard  Line  EDitor  project  is  an  experiment  in  this 
vein.  Several  testbed  implementations  of  STEI  are  now  being 
written.  With  the  completion  of  these  oro^rars,  and  with  the 
continued  support  of  the  Navy  Laboratory  Computer  Committee  and 
the  NICC  Software  Technology  Working  Group,  it  is  hoped  that 
SLEP   may   be   implemented  throughout  the  NALCON.  This  will  ce  a 
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first,  small,  experimental  step  along  the  pathway  to  developing 
effective  and  uniform  software  development  tools  for  use  in 
computer  network  environments. 
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Table  1: 
SLED   Command  Summary 


COMMAND   FUNCTION  USACi 


LINE  INSERTION  ANT  REPLACEMENT  COMMANDS: 

insert  text  After  Line  number  n  ALn  (*) 

insert  text  to  Replace  Lines  n  thru  m  PLn,r  (*] 

or.,  to  insert  text  to  Replace  a  single  Line,  n     ?Ln  (*N 

STRING  REPLACEMENT  COMMANDS 
Replace  all  occurrences  of  String  "p"  with  the       FSn,m$p$q£ 

string  "q"  in  lines  n  thru  m  inclusive. 
or....  ^eplacjf  all  occurrences  of  String  "p"         T>Sn$p$q$ 

with  string  "q"  in  line  n 
or....  Replace  all  occurences  of  String  "p"  RS$p$q$ 

with  string  "q"  in  the  current  line. 

STRING  SEARCH  COMMANDS 
Display  all  lines  containing  String  "p"  TSSp* 

or...  Display  all  lines  betweenf>lines  n  and  m 
inclusive  which  contain  string  "p"  DSn,m$p$ 

OUTPUT  COMMANDS 
set  current  Line  to  n  and  display  that  line         In 

or...  display  the  current  line  L 

or...  display  Lines  n  thru  m  inclusive,  and  set.     In,m 
the  current  line  to  m. 
display  a  "Screen"  of  lines  (22  lines)  beginning     Sr 

with  line  n 

or...  display  a  "Screen"  beginning  with  S 

the  current  line 
display  Version  and  implementation  information       V 
display  <^^enu  of  editor  commands  M 

CONTROL  COMMANDS 
Open  or  Create  a  file  for  editing  o 

Cuit  the  editing  session  and  update  all  files        C 
Change  the  message  Terminator  CI 


X 


The  symbol  "$"  indicates  the  use  of  a  logical  message 
terminator,  not  the  <PFTUPN>  key.  (Sf=e  further  the  text  and 
Figure  2. ) 

(#)   These   commands   cause   the   editor   to  enter  the  TEXT 
INSERT  mode. 
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Figure  1: 
Sample  output  from  «^M>enu  command 

SLED  COMMAND  SUMMARY 

LINE/TEXT  INSERT  STRING  RFPLACEMFNT 
ALn     insert  <A>fter  <L>ine  n     RS$p*q$  ■  0>>e£lare  <S>trinp 
PLn     <R>eplace  <L>ine  n  .or.     RSn^p^q*     "p   with  "q"  in 
RLn,m        lines  n  thru  m         RSn,n$p$q$   inidcated  lines. 

OUTPUT  COMMENTS  STRINC  SFARCH 
I       display  current<L>ine       DS$p$     <D>isplay  lines  wt 
Ln      or  line  n,  string  "p", 

Ln,m    lines  n  thru  m   f>  PSn,m$p$   or  show  any  lines 

S       <S>hov  a  "screen"  of  lines  n-rr  containing  "p" 

Sn      show  a  screen  about  In  #n  CONTROL  COMMANDS 
M       show  command  <^M>enu  (this)   0  '0>per  a  file  or 

V       show  <V>ersior  information     create  e  file  for  editing 

CT   <C>hange  the  logical 
TO  <Q>UIT  TEE  EDIT  TYPE  "Q<ret>"   message  <T>erminator 


Figure  2: 
Sample  output  from  <V>ersion  Command 


SLED  Version  Pasl.l  NPS-Mcnterey  600503 
Local  Expert  is  J.  Doe  406-646-2449  06C7'£-1600  PST 

LINF  DFLFTE  KFY  is  <C0i^TR0L-U> 

CHARACTER  DELETE  KEY  is  <RU13OUT>   (also  called  DELATE ) 

EDITOR  LOGICAL  MESSAGE  TERMINATORS  ARE: 

(1)  <RETURN>     and     (?)  <ESCAPF>  (echo?  "J") 
**  the  message  terminator  can  NOT  be  changed  tc  "line-Feed*  * 

Local  System  supports  UPPFR/lower  case 

Local  System  DID  NOT  require  deviation  fm  SLED  standard 
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Table  ?: 
SLED  Minimum  Advisory  Messages 


Message  Situatior  and  Editor  resporse 

-invalid  command-       in  command  mode  an  unrecognizable 

command  was  issued  (or  an  ambigious 
delimiter  was  used.) 

-n  lines  in  file  "f"-   an  <0>pen  command  on  file  "f"   completed 

successfully. 

-creating  file  "f"-     tried  to  <0>pen  file  "f",  which  did 

not  exist.   A  new  file  is  created. 

-closing  file  "f"-      an  <0>pen  command  was  issued  with  a 

file  already  open.   This  file,  "f" 
is  updated  and  closed,  and  the 
command  proceeds  normally. 

-no  text  file  open-     an  edit  command  was  executed  without 

a  text  file  open. 

-no  string  found-       a  "RS"  or  "DS"  command  was  issucd, 

and  the  search  string  was  not 
found  . 

old  string?^  (A  prompt)  A   "RS"  or  "DS"  command 

was  issued  and  the  first  string 
was  not  specified.   The  editor  new 
waits  for  the  string  to  be  entered 

new  string?>  (A  prompt)  A  "?S"  command  was  issued 

where  the  second  string  was  not 
specified.   The  editor  now  waits 
for  the  string  to  be  entered. 

file  name?>  (A  prompt)  An  <0>pen  command  was 

issued  without  specifying  the  narre 
of  the  file.   The  editor  now 
waits  for  the  file  name  tc  be 
entered . 

terminator?>  (A  prompt)  A  <Ohange  "C^ermirator  coir  mar 

was  issued.   A  valid  ASCII  character  is 
entened  to  act  as  a  nessage  terminator. 
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